Monitoring tickets on transportation systems

ABSTRACT

The present invention provides a computer implemented method, system, and computer program product for monitoring a ticket, the method including receiving credentials by a processing unit from a device via manual presentation of the device to a manual sensor logically coupled to the processing unit, generating a ticket identifier (ID) based on the credentials, transmitting the ticket ID from the processing unit to the device, establishing a wireless connection between the device and the processing unit, checking the wireless connection before each occurrence of an event, checking the wireless connection after each occurrence of the event, and updating a status of a ticket in light of the checking. In an exemplary embodiment, a ticket system includes a processing unit, a manual sensor, a wireless sensor, and a device, where the processing unit transmits the ticket ID, and where the processing unit verifies continued connection at key events.

BACKGROUND

The present invention relates to ticketing systems, and moreparticularly to a computer implemented method, a system, and a computerprogram product for monitoring tickets on transportation systems.

SUMMARY

One aspect of the present invention provides a computer implementedmethod, a system, and a computer program product for monitoring aticket. In an exemplary embodiment, the method including receivingcredentials by a processing unit from a device via manual presentationof the device to a manual sensor logically coupled to the processingunit, generating a ticket identifier (ID) by the processing unit basedon the credentials, transmitting the ticket ID from the processing unitto the device, establishing a wireless connection between the device andthe processing unit, checking the wireless connection before eachoccurrence of an event, checking the wireless connection after eachoccurrence of the event, updating a status of a ticket associated withthe ticket ID in light of the checking, and charging the account a feebased on the status.

Another aspect of the present invention provides, the system includes aprocessing unit, a manual activation sensor logically coupled to theprocessing unit, a wireless sensor capable of reading wirelesssignatures, and a device to interact with the manual activation sensorand the wireless sensor, where the manual activation sensor establishesa first connection channel between the device and the manual activationsensor via manual activation, where the processing unit receivescredentials from the device via the manual activation sensor, where theprocessing unit generates a ticket ID based on the credentials, wherethe processing unit registers the device through the first connectionchannel by at least receiving the credentials from the device, where thewireless sensor establishes a wireless connection through a secondconnection channel between the device and the wireless sensor, where theprocessing unit transmits the ticket ID to the device, where theprocessing unit verifies that the processing unit is able to connectwith the device via the second connection channel before each occurrenceof an event, and where the processing unit verifies that the processingunit is able to connect with the device and that the device is in arange of the processing unit after each occurrence of the event.

Another aspect of the present invention provides, the computer programproduct includes a non-transitory computer readable storage mediumhaving program instructions embodied therewith, the program instructionsreadable and executable by a processor to cause the processor to performa method including receiving credentials by a processing unit from adevice via manual presentation of the device to a manual sensorlogically coupled to the processing unit, generating a ticket ID by theprocessing unit based on the credentials, transmitting the ticket IDfrom the processing unit to the device, establishing a wirelessconnection between the device and the processing unit, checking thewireless connection before each occurrence of an event, checking thewireless connection after each occurrence of the event, updating astatus of a ticket associated with the ticket ID in light of thechecking, and charging the account a fee based on the status.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart according to an embodiment of the presentinvention.

FIG. 2A is a side view of a vehicle with the ticketing system accordingto an embodiment of the present invention.

FIG. 2B is a side view of a vehicle with the ticketing system accordingto an embodiment of the present invention.

FIG. 3 depicts a processing unit, according to various embodiments.

DETAILED DESCRIPTION

The present invention provides a computer implemented method, a system,and a computer program product for monitoring a ticket. In an exemplaryembodiment, the method includes receiving credentials by a processingunit from a device via manual presentation of the device to a manualsensor logically coupled to the processing unit, generating a ticketidentifier (ID) by the processing unit based on the credentials,transmitting the ticket ID from the processing unit to the device,establishing a wireless connection between the device and the processingunit, checking the wireless connection before each occurrence of anevent, checking the wireless connection after each occurrence of theevent, updating a status of an account associated with the ticket ID inlight of the checking, and charging the account a fee based on thestatus. In one embodiment, the present invention is used as a ticketingsystem on a mass transit vehicle such as a train, trolley, or bus. Forexample, a passenger of a mass transit vehicle could use his/her deviceto manually check in, and then the processing unit could record for howlong or for how many stops the device is on the vehicle. In oneembodiment, the system is used on a bus. In one embodiment, the event isthe opening and closing of the bus door. One embodiment of the inventionallows for the processing unit to track when the device gets on and offthe bus. The two-check system, one check before the event and one checkafter the event, could allow for a particular passenger to get off thevehicle to allow other passengers room to exit and then, for theparticular passenger to re-board the vehicle before the second check.

Some existing bus systems require passengers to manually check in whengetting on a bus and manually check out when getting off the bus.However, the design of these systems creates two issues.

The first issue is ticket evading. Current ticketing systems contain apotential risk which could be used by freeloaders to evade the ticketfee. This could result in economic loss for bus companies. For example,if a passenger checks out at an earlier stop of a vehicle and thepassenger gets off the vehicle, the present invention would only chargethe passenger for part of the actual ride of the passenger.

Ticket evading is a very common and serious problem in the world. InChile, the bus system suffers from significant losses every year. Also,the Nanjing metro suffers from significant losses due to ticket evading,e.g. a loss of 8 million RMB. Similarly, the French mass transit systemsuffers from significant losses due to freeloading, e.g. a loss of 500million euro.

In one embodiment, the present invention solves the ticket evading issueby implementing a twostep exit procedure. Once a ticket is checked intothe system, the system will check the ticket before and after each stop.If a passenger shields a ticket device to give a false checkout, thesystem will register that it prematurely lost the connection to theticket device. The device will then charge an account associated withthe ticket a fee.

In another embodiment, the present invention solves the ticket evadingissue by monitoring the signal strength of the ticket device before thesystem loses connection with the device. If the profile of the signalloss does not match a standard profile associated with a ticket devicemoving off of a vehicle, the system will be able to determine that thedevice was intentionally shielded to avoid the ticket fee. In oneexample, the signal strength of the ticket device will become weakergradually as the passenger walks away from the vehicle or the vehiclemoves away from the passenger. If the passenger shields the ticketdevice, the abrupt signal loss will enable the system determine thatdevice was being shielded to evade the ticket fee. The system can thencharge an account associated with the ticket a penalty fee.

The second limitation is inconvenience. When passengers disembark from acrowded bus, manually checking out one by one at the bus station couldcause congestion. This could lead to safety problems due to thecongestion at those checkout points.

Existing ticketing systems either do not prevent freeloading or make thepassengers swipe out with a physical ticket. In one embodiment, thepresent invention allows for an automatic check out by wirelesslylogging tickets of passengers as they get off the vehicle without anymanual interaction, thereby preventing freeloading and making thecheckout process more convenient for passengers by keeping their handsfree. In one embodiment of the present invention, a ticket system checksthe status of the ticket by wireless signal without requiring the userto interact with a ticket device or the system during the checkoutprocess. The ticket system is able to determine when the ticket deviceshould be checked out by monitoring when the ticket device loses itsconnection to the ticket system.

Existing ticketing systems do not have real time monitoring of thestatus of passenger. In one embodiment of the present invention, WI-FIis used to monitor the status (on or off the bus) of passengers in realtime.

In some existing wireless ticketing systems, there is the potential toevade the ticketing system by shielding a device. In one embodiment ofthe present invention, a twice check mechanism prevents ticket evadingby intentional or unintentional signal shielding, and records whether ornot a passenger got off the bus.

Manual checkout systems may cause congestion near the checkout terminalat each stop. In one embodiment of the present invention, when the busis crowded, passengers will not have to wait in line to manually checkout, thereby preventing congestion and related security risks. Theticket system will monitor when each ticket device loses connection withthe ticket system, the ticket system will then check out the ticketdevice automatically.

Currently it is hard to accurately track data for how long passengersride and what portion of the routes passengers ride on mass transit. Inone embodiment of the present invention, the data obtained from thepresent invention is logged for big data and cloud companies. The datacould then be used for statistical analysis and data mining.

Installing expensive new equipment for ticketing systems may be costprohibitive. In one embodiment, the present invention utilizes someexisting equipment on mass transportation systems. For example, thepresent invention is compatible with Wi-Fi technology presentlyinstalled on many mass transit vehicles. For passengers, mobile paymentis increasingly popular. The present invention could be combined withmobile devices by using a mobile device as ticket card.

Referring to FIG. 1, in one embodiment the present invention provides amethod 100 including a step 110 of receiving credentials by a processingunit from a device via manual presentation of the device to a manualsensor logically coupled to the processing unit, a step 120 ofgenerating a ticket ID by the processing unit based on the credentials,a step 130 of transmitting the ticket ID from the processing unit to thedevice, a step 140 of establishing a wireless connection between thedevice and the processing unit, a step 150 of checking the wirelessconnection before each occurrence of an event, a step 160 of checkingthe wireless connection after each occurrence of the event; a step 170of updating a status of an account associated with the ticket ID inlight of the checking, and a step 180 of charging the account a feebased on the status.

In one embodiment, the event includes opening and closing of a door on avehicle that includes the processing unit. In one embodiment, thevehicle is a public transit bus, and the event is the opening andclosing of the rear door of the vehicle. In an embodiment, theprocessing unit runs a check before the door opens and after the doorcloses. In a further embodiment, the check before the door is openverifies that the processing unit can still connect to the device. In afurther embodiment, the processing unit connects or tries to connect tothe device after the door is shut. If the device is outside of a certainsignal strength, then the processing unit determines that the device isno longer on the bus and closes out the ticket, assuming the passengerhas ended the ride. In a further embodiment, the processing unit checksto see that the device is still connected before opening the door. Whenthe processing unit loses connection before the door is opened, theprocessing unit triggers an exception to prevent people fromintentionally shielding their devices. If the processing unit did notperform this check, the processing unit would falsely record that adevice got off at an earlier stop. An exception would also account for adevice malfunctioning.

In one embodiment, the checking includes recording a signal strength ofthe wireless connection, and comparing the signal strength to a lookuptable to determine a distance of the device from the processing unit. Inan embodiment, by comparing the signal strength to a table with knownsignal strengths at different distances, the location of the device isdetermined. In one embodiment, once a device is farther away than theextent of a vehicle, the processing unit determines that the device isno longer on the vehicle.

In another embodiment, the present invention solves the ticket evadingissue by monitoring the signal strength of the ticket device before thesystem loses connection with the device. If the system abruptly loses aconnection with the device, the system will be able to determine thatthe device was intentionally shielded to avoid the ticket fee.

In one embodiment, the checking further includes generating an exceptionvalue indicating a loss of the wireless connection during the checkingbefore an occurrence of the event. In one embodiment, the exceptionvalue is processed as the device is being shielded or is powered down.In a particular embodiment, an associated account is charged a fee forthe exception value.

In one embodiment, the updating includes charging an account associatedwith the ticket ID a fee based on the exception value. In a furtherembodiment, the fee charged could be for the entire route of the bus. Inan alternative embodiment, the fee charged could be a fee associatedwith the normal route for that device. For example, if a device isnormally taken from stop A to stop D, but the device is shielded orpowered down before stop C, then the processing unit could charge anaccount associated with the device the full fare from stop A to stop D.In an alternative embodiment, the fee could be a flat fee.

In one embodiment, the device is a portable electronic device. In aparticular embodiment, the device is a mobile phone. In an alternativeembodiment, the device is a tablet computer. In an alternativeembodiment, the device is a card with embedded wireless technology. In afurther embodiment, the card has a magnetic strip.

In one embodiment, the method further includes determining a location ofthe device via at least one sensor. In a further embodiment, threesensors could be used to triangulate the position of the device. In analternative embodiment, two sensors could be used to narrow down thelocation of the device such that if one sensor were placed at the frontcenter of a bus and another sensor were placed at the back center of thebus, the sensors could accurately determine if the device was stilllocated on the bus. Thus, the two-check system could be used todetermine when the device gets off the bus.

Referring to FIG. 2A and 2B, in one embodiment, a ticket system includesa processing unit 210 installed on a vehicle 200, a manual activationsensor 220 logically coupled to processing unit 210, a wireless sensor230 capable of reading wireless signatures, and a device 240 to interactwith manual activation sensor 220 and wireless sensor 230, where manualactivation sensor 220 establishes a first connection channel betweendevice 240 and manual activation sensor 220 via manual activation, whereprocessing unit 210 receives credentials from device 240 via the manualactivation sensor 220, where processing unit 210 generates a ticketidentifier (ID) based on the credentials, where processing unit 210registers device 240 through the first connection channel by at leastreceiving the credentials from device 240, where wireless sensor 230establishes a wireless connection through a second connection channelbetween device 240 and wireless sensor 230, where processing unit 210transmits the ticket ID to device 240, where processing unit 210verifies that processing unit 210 is able to connect with device 240 viathe second connection channel before each occurrence of an event, andwhere processing unit 210 verifies that processing unit 210 is able toconnect with device 240 and that device 240 is in a range of processingunit 210 after each occurrence of the event. FIG. 2A depicts device 240on vehicle 200, and FIG. 2B depicts device 240 off vehicle 200.

In one embodiment, device 240 is used by a passenger on a vehicle 200that has the ticket system. For example, as the passengers enter vehicle200, device 240 is brought close to or touches manual activation sensor220. In a further embodiment, manual activation sensor 220 is one of apassive proximity card reader, an active proximity card reader, amagnetic stripe card reader, a smart card reader, a chip card reader, anintegrated circuit card reader, a photo identification reader, amechanical holecard reader, and a barcode reader. In a furtherembodiment, once processing unit 210 recognizes device 240, device 240connects to processing unit 210 wireles sly and maintains thatconnection throughout the duration of the transit. In one embodiment,vehicle 200 makes multiple stops, and processing unit 210 checks device240 to see if device 240 is still on vehicle 200 before and after eachstop. For example, processing unit 210 could ensure that device 240 isnot being tampered with and could determine if device 240 is still onvehicle 200 after each stop. Also, for example, checking to see thatdevice 240 is still on vehicle 200 after the stop could ensure thatdevice 240 of a passenger does not end the ride of the passenger whoonly briefly gets off vehicle 200 during the stop.

In one embodiment, the event includes opening and closing of a door onvehicle 200, vehicle 200 includes processing unit 210.

In one embodiment, processing unit 210 records a signal strength of thewireless connection and compares the signal strength to a lookup tableto determine a distance of device 240 from processing unit 210. In oneembodiment, the strength of the signal degrades as device 240 moves awayfrom a vehicle 200, with processing unit 210 installed, or as vehicle200 moves away from device 240. For example, by monitoring the signalstrength, processing unit 210 could use the signal strength and a lookuptable to determine the distance of device 240 from processing unit 210,and once device 240 is far enough away from processing unit 210,processing unit 210 could determine that device 240 is no longer onvehicle 200.

In one embodiment, processing unit 210 generates an exception value dueto a loss of the wireless connection before the occurrence of the event.In a further embodiment, processing unit 210 generates a differentexception value for different types of losses. For example, processingunit 210 could have a different exception value if the wirelessconnection becomes weak, if device 240 sends out a signal that power islow before the loss of the connection, if device 240 is suddenly cutoff, or if the connection is intermittent such that each wirelessconnection profile could have a different exception value based on theprobable cause of the wireless connection loss or change. In a furtherembodiment, the ramification of the exception value can meet theprobable cause. For example, if device 240 is being tampered with so asto appear as if device 240 is no longer on vehicle 200, an accountassociated with device 240 could be charged a penalty. In anotherexample, when device 240 loses power, processing unit 210 coulddetermine that device 240 was not intentionally shut down and couldcharge an account associated with device 240 a base fare. In a furtherembodiment, processing unit 210 has longer term analytics that run overmultiple uses of device 240 such that processing unit 210 generatesfurther exception values/exceptions based on the analysis of thatsituation. For example, if a device 240 is shut down on multiple rides,processing unit 210 could determine that the shutdowns were intentionaland could charge a penalty instead of a base rate.

In one embodiment, the manual activation includes touching device 240 tomanual activation sensor 220. In one embodiment, device 240 could besimilar to an ID card that requires touching the ID card to manualactivation sensor 220. In an embodiment, touching means bringing device240 close enough to manual activation sensor 220 for a close-rangeconnection method to take place in order to verify that device 240 is onvehicle 200 with processing unit 210 and has been used to check in for aride on vehicle 200. For example, the close manual activation couldprevent a false ride from being activated by someone who is in closeproximity to the vehicle 200 and could allow a driver of vehicle 200 toverify that each individual who gets on the vehicle 200 has been checkedin. In one embodiment, processing unit 210 has a display that shows thestatus of each device 240 as each device 240 is checked in and accountinformation associated with device 240. In one embodiment, processingunit 210 gives a tone signaling if each device 240 has a valid accountassociated with device 240 as each device 240 is manually checked in.For example, one tone could signal the successful acquisition of aticket for the account associated with device 240, and one tone couldsignal the failure to acquire a ticket for the account associated withdevice 240.

In one embodiment, device 240 is a portable electronic device 240. Thepresent invention is compatible with any portable device 240 that isable to send a wireless signal or that can be read wirelessly. In oneembodiment, device 240 could be a smart phone. In an alternativeembodiment, device 240 is a personal ID card. In one embodiment, device240 has an imbedded RFID chip.

In one embodiment, the system further includes one or more sensors todetermine the location of device 240. In one embodiment, the sensorsdetermine the direction of device 240 by having two sensors recordingthe direction from which the signal is coming. In one embodiment, two ormore sensors measure the signal strength of device 240 and determine thelocation of device 240 based on the signal strength recorded by each ofthe sensors.

In one embodiment, a processing unit for managing tickets includes aprocessing unit having a manual sensor and a wireless sensor, a devicecapable of interacting with the processing unit, where the processingunit establishes a manual connection channel between the device and theprocessing unit, where the processing unit establishes one or morewireless connection channels between the device and the processing unit,where wireless connections are timed to be coordinated with criticalticket events.

In one embodiment, the processing unit measures the signal as a vehicle,with the processing unit on the vehicle, leaves a stop. Once the signalgets weak enough, the processing unit could determine that the devicewas left at the stop and could charge an account associated with thedevice for the ride. In an alternative embodiment, the processing unitchecks to see if the device is connected after a vehicle, with theprocessing unit on the vehicle, leaves a stop. If the device is nolonger connected, the processing unit can determine that the device wasleft at the stop and charge an account associated with the device.

In one embodiment, a first type of critical ticket event occurs before avehicle door is open and a second type of critical ticket event occursafter the vehicle door is closed, where the vehicle includes aprocessing unit. In one embodiment, the critical ticket events occurwhen the processing unit needs to determine the location of the device.In one embodiment, a critical ticket event occurs periodicallythroughout a trip of a vehicle in which the processing unit isinstalled. In one embodiment, one critical ticket event occurs before astop of a vehicle in which the processing unit is installed, and asecond critical ticket event occurs after a stop of the vehicle. Thecritical ticket events allow the processing unit to determine theportion of the trip that the device is on the vehicle.

In one embodiment, the processing unit generates an exception inresponse to a failure of the device to connect at the first criticalticket event. The exception can be a fine, an increased fare, or ageneration of an estimated duration of time in which the device is on avehicle in which the processing unit is installed.

In one embodiment, the processing unit records a signal strength of thewireless connection channel and compares the signal strength to a lookuptable to determine the distance of the device from the processing unit.In one embodiment, a baseline signal strength is recorded at the sametime the device is manually checked in. In one embodiment, a baselinesignal strength is recorded directly after the manual check in. In afurther embodiment, the baseline signal strength is used to determinethe signal strength values for the lookup table. For example, a weakbaseline signal strength will lower signal strengths for relativelocations on the lookup table, where a strong baseline signal strengthwill have higher signal strengths for relative locations on the lookuptable. In one embodiment, processing unit can include a computer system.

In one embodiment, a manual connection includes at least one of areceptacle or a touch pad to contact the device and a proximity receiverto connect with the device. The manual connection can use any technologythat requires direct interaction or proximity interaction of the devicewith the processing unit.

In one embodiment, at least one sensor is used to determine the locationof the device. In one embodiment, the sensor determines the location ofthe device based on the signal strength or any other location method fordetermining the location or direction of the device.

The present invention may be a system, a method, and/or a computerprogram product at any possible technical detail level of integration.The computer program product may include a computer readable storagemedium (or media) having computer readable program instructions thereonfor causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state information ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

FIG. 3 shows an exemplary embodiment of a computer system, computersystem 300. Computer system 300 is only one example of a computer systemand is not intended to suggest any limitation as to the scope of use orfunctionality of embodiments of the present invention. Regardless,computer system 300 is capable of being implemented to perform and/orperforming any of the functionality/operations of the present invention.

Computer system 300 includes a computer system/server 302, which isoperational with numerous other general purpose or special purposeprocessing unit environments or configurations. Examples of well-knownprocessing units, environments, and/or configurations that may besuitable for use with computer system/server 302 include, but are notlimited to, personal computer systems, server computer systems, thinclients, thick clients, hand-held or laptop devices, multiprocessorsystems, microprocessor-based systems, set top boxes, programmableconsumer electronics, network PCs, minicomputer systems, mainframecomputer systems, and distributed cloud computing environments thatinclude any of the above systems or devices, and the like.

Computer system/server 302 may be described in the general context ofcomputer system-executable instructions, such as program modules, beingexecuted by a computer system. Generally, program modules may includeroutines, programs, objects, components, logic, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Computer system/server 302 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program modules may be locatedin both local and remote computer system storage media including memorystorage devices.

As shown in FIG. 3, computer system/server 302 in cloud computing node300 is shown in the form of a general-purpose computing device. Thecomponents of computer system/server 302 may include, but are notlimited to, one or more processors or processing units 310, a systemmemory 360, and a bus 315 that couple various system componentsincluding system memory 360 to processor 310.

Bus 315 represents one or more of any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. By way of example, and notlimitation, such architectures include Industry Standard Architecture(ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA)bus, Video Electronics Standards Association (VESA) local bus, andPeripheral Component Interconnects (PCI) bus.

Computer system/server 302 typically includes a variety of computersystem readable media. Such media may be any available media that isaccessible by computer system/server 302, and it includes both volatileand non-volatile media, removable and non-removable media.

System memory 360 can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 362 and/or cachememory 364. Computer system/server 302 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 366 can be provided forreading from and writing to a non-removable, non-volatile magnetic media(not shown and typically called a “hard drive”). Although not shown, amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and an optical diskdrive for reading from or writing to a removable, non-volatile opticaldisk such as a CD-ROM, DVD-ROM or other optical media can be provided.In such instances, each can be connected to bus 315 by one or more datamedia interfaces. As will be further depicted and described below,memory 360 may include at least one program product having a set (e.g.,at least one) of program modules that are configured to carry out thefunctions of embodiments of the invention.

Program/utility 368, having a set (at least one) of program modules 369,may be stored in memory 360 by way of example, and not limitation, aswell as an operating system, one or more application programs, otherprogram modules, and program data. Each of the operating system, one ormore application programs, other program modules, and program data orsome combination thereof, may include an implementation of a networkingenvironment. Program modules 369 generally carry out the functionsand/or methodologies of embodiments of the invention as describedherein.

Computer system/server 302 may also communicate with one or moreexternal devices 340 such as a keyboard, a pointing device, a display330, etc.; one or more devices that enable a user to interact withcomputer system/server 302; and/or any devices (e.g., network card,modem, etc.) that enable computer system/server 302 to communicate withone or more other computing devices. Such communication can occur viaInput/Output (I/O) interfaces 320. Still yet, computer system/server 302can communicate with one or more networks such as a local area network(LAN), a general wide area network (WAN), and/or a public network (e.g.,the Internet) via network adapter 350. As depicted, network adapter 350communicates with the other components of computer system/server 302 viabus 315. It should be understood that although not shown, other hardwareand/or software components could be used in conjunction with computersystem/server 302. Examples, include, but are not limited to: microcode,device drivers, redundant processing units, external disk drive arrays,RAID systems, tape drives, and data archival storage systems, etc.

The descriptions of the various embodiments of the present inventionhave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

What is claimed is:
 1. A computer implemented method for monitoring aticket, the method comprising: receiving credentials by a processingunit from a device via manual presentation of the device to a manualsensor logically coupled to the processing unit, wherein the device is aportable electronic device, wherein the receiving comprises touching thedevice to the manual sensor, wherein the device has an imbedded RFIDchip; generating a ticket identifier (ID) by the processing unit basedon the credentials; transmitting the ticket ID from the processing unitto the device; establishing a wireless connection between the device andthe processing unit; recording a baseline signal strength directly afterthe manual presentation; checking the wireless connection before eachoccurrence of an event; checking the wireless connection after eachoccurrence of the event, wherein the event comprises opening and closingof a door on a vehicle that includes the processing unit, wherein thechecking the wireless connection before each occurrence of the eventcomprises recording a first signal strength of the wireless connection,wherein the checking the wireless connection before each occurrence ofthe event comprises comparing the first signal strength to a lookuptable to determine a distance of the device from the processing unit,wherein the checking the wireless connection after each occurrence ofthe event comprises recording a second signal strength of the wirelessconnection, wherein the checking the wireless connection after eachoccurrence of the event comprises comparing the second signal strengthto a lookup table to determine a distance of the device from theprocessing unit; determining a location of the device via at least onesensor; generating an exception value indicating a loss of the wirelessconnection during the checking before an occurrence of the event;recording the device has been shutdown; retrieving information statingthe device has been shutdown on multiple rides; determining that theshutdowns were intentional; updating a status of an account associatedwith the ticket ID in light of the checking; and charging the account afee based on the status, wherein the fee is a penalty based on thedetermination that the shutdowns were intentional.